I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

Optimize final row selection for a binary if when the result is numeric or decimal.

The generic evaluator selects every row through type-erased scalar values and a generic column builder. This is expensive after the condition and both result branches have already been evaluated.

Implementation

• Add a typed selector for a single-condition binary if
• Support numeric and decimal outputs, including nullable variants
• Handle scalar/scalar, scalar/column, column/scalar, and column/column results
• Keep the existing generic selector for multi-branch and unsupported result types
• Add golden tests for non-nullable Int64 and Decimal64 results

The typed path is used only when the block has a known row count, the if has exactly one condition, and the result type is supported.

Performance

This is an evaluator benchmark, not an end-to-end databend-query SQL benchmark.

The benchmark uses the production release profile, 30 samples per case, and two block sizes:

• 65,536 rows: the default max_block_size
• 1,048,576 rows: a larger stress case

Expression parsing, type checking, and input construction are outside the timed section. Evaluator::run and output allocation are timed. Divan drops the returned output after the timed section.

Both revisions were built as separate release binaries. The binaries were pinned to CPU 1 and run five times in balanced interleaved order on an otherwise idle 16-CPU host. The tables report the median of the five Divan medians.

Numeric results

The numeric reduction is large and directionally consistent at both block sizes.

Unsupported Boolean fallback

if_boolean returns Boolean, so it does not use the new typed selector and continues through the existing generic selector.

The after revision is consistently slower for this case in this evaluator microbenchmark. The added fallback work is one output-type dispatch per block, while the measured gap grows with the number of rows, so that dispatch cannot explain the result. Treat this as an unresolved regression: the current benchmark times condition evaluation, both result branches, and final selection together, and does not yet identify which stage regressed.

Absolute times depend on the machine. Run the comparison locally and focus on matching cases and row counts.

Reproduce

The first commit contains only the benchmark and measures the old evaluator. The second commit adds the optimization without changing the benchmark.

On Linux, build first and then pin the cached benchmark run to one CPU:

git switch --detach 365900f8b7

env CARGO_TARGET_DIR=target/numeric-if-before \
  cargo bench --profile release \
  -p databend-common-functions --bench bench --no-run

taskset -c 1 env CARGO_TARGET_DIR=target/numeric-if-before \
  cargo bench --profile release \
  -p databend-common-functions --bench bench -- numeric_if

git switch --detach ad085925ef

env CARGO_TARGET_DIR=target/numeric-if-after \
  cargo bench --profile release \
  -p databend-common-functions --bench bench --no-run

taskset -c 1 env CARGO_TARGET_DIR=target/numeric-if-after \
  cargo bench --profile release \
  -p databend-common-functions --bench bench -- numeric_if

On systems without taskset, omit that prefix. Run on an idle machine and compare matching cases and row counts. For lower noise, repeat before and after in alternating order and compare medians. The output also reports rows per second.

--profile release is intentional: the repository bench profile enables debug assertions, while the production release profile does not. Separate target directories prevent Cargo artifacts from being reused across revisions.

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Explain why

Commands run:

cargo fmt --all -- --check
cargo test -p databend-common-functions --test it scalars::control::test_control
cargo clippy -p databend-common-expression -p databend-common-functions --all-targets -- -D warnings
cargo bench --profile release -p databend-common-functions --bench bench -- numeric_if

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

AI assistance

• AI usage: An AI coding agent verified the port onto current main, separated the benchmark baseline from the implementation, audited the benchmark timing and release profile, added reproducible block-size benchmarks, ran correctness, lint, and performance validation, and drafted this PR description
• Responsible human: @dantengsky
• The responsible human has read every line of this diff and can explain each change

This change is